
i ■ 



PATENT APPLICATION 
ATTORNEY DOCKET NO. 22971 .NP / 3003.2.9A 

IN THE UNITED STATES PATENT & TRADEMARK OFFICE 



ART UNIT: 2155 



EXAMINER: Thu Ha Nguyen 

APPLICANT: Sanchaita Datta and Ragula Bhaskar 

SERIAL NO.: 10/034,197 



FILED: 



December 28, 2001 



FOR: COMBINING CONNECTIONS FOR 
PARALLEL ACCESS TO MULTIPLE 
FRAME RELAY AND OTHER PRIVATE 
NETWORKS 



APPEAL BRIEF 




!>«fthereby?cmifvtha thisw 




Brief? -' Patents; Somm^ 






Mail Stop Appeal Brief - Patents 
Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 223134450 

Commissioner: 

Applicants and Assignee hereby appeal from the Final Office Action mailed April 19, 
2004. The Notice of Appeal was filed July 14, 2004. This application has been granted 
accelerated examination status. 



Third Party Submission 

The Final Office Action does not refer to the third-party submission that was filed, on 
behalf of an unidentified third party, on or about April 5, 2004. References were submitted to the 
Office by a third party in each of the following applications of the Assignee: 10/034190, 
10/034197, 10/361837, 10/263497. That submission was made two weeks before the mailing of § 
the Final Office Action, but it is not clear to the undersigned whether the Examiner has yet 
received and considered the submission's references. If copies of the submission's references 
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have not reached the Examiner, they will be submitted by the undersigned on request. 
Otherwise, the undersigned will assume that the Examiner does have copies of the third-party 
submission references and has considered them before answering this Appeal Brief. The 
undersigned respectfully submits that this approach is consistent with the Office's laudable effort 
to reduce unnecessary paperwork. 

Real Party in Interest 

The real party in interest in this appeal is Assignee, Ragula Systems (FatPipe Networks). 

Related Appeals and Interferences 

None. 

Status of Claims 

Claims 1-21 were rejected in the Final Office Action, are still pending, and are now 
appealed. 

Status of Amendments 

No amendments were filed after the Final Office Action. However, a detailed Interview 
Summary was filed on May 25, 2004. 

Summary of Invention 

The present invention relates to tools and techniques for accessing multiple independent 
frame relay networks and/or point-to-point (e.g., Tl or T3) network connections in a parallel 
network configuration, as shown for instance in Figure 5 or Figure 6. Frame relay networks 106 
and point-to-point networks are each "private networks"; see application at page 9 lines 10-12. 
In some embodiments a controller 502 according to the invention comprises a site interface 702 
connecting the controller to a site 102, at least two private network interfaces 706, and a packet 
path selector 704 which selects between private network interfaces according to a specified 
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criterion. A site may include a local area network; see discussion of Figure 7 on pages 13-14, 
and page 17 lines 15-17. 

The controller receives 804 a packet through the site interface and sends 814 the packet 
through the private network interface that was selected 806 by the packet path selector. The 
controller's packet path selector selects between private network interfaces according to various 
criteria, such as (a) a load-balancing criterion 808 that promotes balanced loads on devices that 
carry packets after the packets leave the selected private network interfaces; (b) a reliability 
criterion 810 that promotes use of devices that will still carry packets after the packets leave the 
selected private network interfaces, when other devices that could have been selected are not 
functioning, and (c) a security criterion 812 that promotes use of multiple private networks to 
cany different pieces of a given message so that unauthorized interception of packets on fewer 
than all of the networks used to carry the message will not provide the total content of the 
message. 

The invention also provides other controller embodiments, and it provides method 
embodiments. The claims define the invention; this summary is provided merely as an 
introduction and to assist in understanding the claims. 



Issues 

1 . Is a local area network a "private network" as that term is defined by applicants? 

2. Were claims 1, 3, and 8-9 properly rejected under Section 102 in view of U.S. Patent 
No. 5,948,069 by Kitai et al. ("Kitai")? 

3. Were claims 2, 4, 1 1, and 13-16 properly rejected under Section 103 in view of Kitai 
combined with U.S. Patent No. 5,910,951 to Pearce et al. ("Pearce")? 

4. Were claims 5 and 17 properly rejected under Section 103 in view of Kitai combined 
with U.S. Patent No. 6,546,423 to Dutta et al. ("Dutta")? 

5. Were claims 6 and 7 properly rejected under Section 103 in view of Kitai combined 
with U.S. Patent No. 6,195,680 to Goldszmidt et al. ("Goldszmidt")? 

6. Were claims 10, 12, and 18 properly rejected under Section 103 in view of Kitai 
combined with U.S. Patent No. 6,209,039 to Albright et al. ("Albright")? 
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7. Were claims 19-21 properly rejected under Section 103 in view of Kitai combined 
with Pearce and also combined with Goldszmidt? 

Grouping of Claims 

Solely for purposes of this appeal, the claims are grouped as follows: 



Group II: claims 2, 4, 1 1, and 13-16 
Group III: claims 5 and 17 
Group IV: claims 6 and 7 
Group V: claims 10, 12, and 18 
Group VI: claims 19-21 

In this appeal, each claim in a given group stand or fall together. 



By way of context, the following papers are among those filed or mailed in this case: 



Group I: 



claims 1, 3, and 8-9 



Argument 



Provisional 



provisional application, filed December 29, 2000 



Application 



non-provisional application, filed December 28, 2001 
information disclosure statement, filed April 29, 2002 
information disclosure statement, filed March 14, 2003 
information disclosure statement, filed April 9, 2003 
information disclosure statement, filed April 1 1 , 2003 
petition to accelerate examination, filed April 21, 2003 
information disclosure statement, filed June 3, 2003 



First IDS 



Second IDS 



Third IDS 



Fourth IDS 



Petition 



Fifth IDS 



Petition Grant 




First Action 



Response 
Third-Party 



Final Action 
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Interview Summary interview summary, filed May 25, 2004 
Appeal Notice notice of appeal, filed July 14, 2004 

The shortcomings of the rejections will now be reviewed. Arguments and statements by 
Applicants made earlier but not repeated here are also part of the record for this appeal and are 
not waived, although they may be modified or supplemented here. To keep this brief short while 
still trying to provide an adequate basis for review, some observations and arguments that might 
have been presented are not included. Accordingly, Applicants' silence here with respect to 
particular statements by the Office does not indicate their agreement or acquiescence. 

A local area network is not a "private network" (Groups I - IV. VP 

Each rejection, under Section 102 or under Section 103, depends on Kitai. With the 
possible exception of Group V claims, whose rejection is based in part on Albright (a reference 
that discusses frame relay networks at length and in detail), the claim rejections all apparently 
rely on the Examiner's assertion that the claim term "private network" includes the local area 
network disclosed in Kitai. Applicants and Assignee agree with the Examiner that Kitai 
discloses local area networks (LANs). But they do not agree that a LAN is a "private network" 
as used in the claims. A LAN is not a private network. 

The meaning of "private networks" depends on the specification, and on skill in the art. 
The term "private network" was coined for use in the present application - its first appearance in 
the body of the specification is in quotes. It is an exercise of the well-established right of patent 
applicants to be their own lexicographers. Accordingly, the specification must be considered 
when determining what is and what is not meant by "private network". See M.P.E.P. § 21 1 1 
(PTO gives claims their broadest reasonable meaning while "taking into account whatever 
enlightenment by way of definitions or otherwise that may be afforded by the written description 
contained in applicant's specification"). "Private network" can only be given a meaning that is 
consistent with the examples and discussion in the application. 

As explained in the Response, "private networks" are defined and exemplified in the 
application to include frame relay networks and/or point-to-point networks: 
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"Frame relay networks are an example of a 'private network'. Another example is a 
point-to-point network, such as a Tl or T3 connection/ 9 Application at page 2 lines 3-4. 
" 'Frame relay networks' or 'private networks' does not rule out the use of an ISDN link 
or other backup for a particular frame relay or point-to-point private network, but it does 
require the presence of multiple such networks - Figure 2, for instance, does not meet this 
requirement" Application at page 9 lines 16-20. 

"The present invention provides tools and techniques for accessing multiple independent 
frame relay networks and/or point-to-point (e.g., Tl or T3) network connections in a 
parallel network configuration." Application at page 5 lines 20-22 (summary of 
invention). 

The application does not state that a LAN is a private network; if it did, the Examiner's 
interpretation would be correct On the other hand, the application does not contain an express 
contrary statement such as "a LAN is not a private network". The usefulness of such a statement 
was not apparent during preparation of the application. It simply did not occur to the 
undersigned while preparing the application that someone might read "private network" to 
include LANs. 

Accordingly, the broadest reasonable interpretation of the claims must be consistent both 
with the specification and with the interpretation that those skilled in the art would reach. 
M.P.E.P. §2111. We therefore face the question of how the term "private network" would be 
understood by one of skill in the art who read the application to gather the intended meaning of 
that term. 

A person of skill understands that LANs are not WANs, and that frame relay implies a 

WAN. It is undisputed that a person of skill in the art would understand certain things even 

before reading the application. For instance, one skilled in the art would understand the 

following definitions, or similar definitions: 

LAN (n.) Local area network, a network of multiple interconnected data terminals or 
devices within a local area to facilitate data transfer. Most notable of LAN topologies is 
ethernet, token ring, FDDI, etc. 
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WAN (n.) Wide area network, a network of circuits spanning a large region or global in 
proportions, that is used to transmit data between widespread subscribers. See also LAN. 

FRAD (n.) Frame relay assembler/disassembler, used to interface a LAN with a frame 
relay WAN. 

"High Performance Computing and Communications Glossary 2.1" (1993, 1995) (at 
http://wotug.ukc.ac.uk/parallel/acronyms/hpccgloss) 

Likewise, one of skill would understand that the differences between LANs and WANs 

go beyond the differences in their geographic scope. For instance, one skilled in the art would 

have an understanding of the following passage: 

Remote bridging presents several unique internetworking challenges, one of which is the 
difference between LAN and WAN speeds. Although several fast WAN technologies 
now are establishing a presence in geographically dispersed internetworks, LAN speeds 
are often an order of magnitude faster than WAN speeds. Vast differences in LAN and 
WAN speeds can prevent users from running delay-sensitive LAN applications over the 
WAN. 

"What is Bridging?" (Cisco Systems; copyright 2000) (at 
http://www.pulsewan.com/datal01/bridging_basics.htm) (emphasis added) 

One of skill would also associate frame relay with WANs, not with LANs. This is clear 
from the definition of FRAD above. It is also apparent in the puzzled question "How would 
there be Frame Relay in a LAN environment?" in the following posting: 

Re; Encapsulation for LAN emulation 

• From : comp. dcom. cell-reloy@usenet. ucs. indiana. edu 

• Date: Thu, 5 May 1994 17:53:59 -0500 

• X-Originally-From: rajeev@trillium.com 

V. Srinivas writes, 

> Is there any move towards providing LAN emulation on the Frame Relay 

> ATM intterworking scenario also ? 

LAN Emulation is currently being defined for IEEE 802.3 and 802.5 
only. I don't understand the "LAN emulation on the Frame Relay ATM 
intterworking scenario". How would there be Frame Relay in a LAN 
environment? Of course if LAN Emulation is carried over an ATM 
network that interworks with a Frame Relay network to provide 
end-to-end connectivity, then sure your scenario exists, but that 
is transparent to LAN Emulation. 



Rajeev Gupta Email : rajeev@trillium.com 

Trillium Digital Systems, Inc. Voice <w) : (310) 479-0500 
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2001 S. Barrington Ave., Suite 215 Fax (w) : (310) 575-0172 
Los Angeles, CA 90025. 

(at http: //cell-relay . indiana . edu/mhonarc/cell-relay/1994-May/msg00091 .html) 

The definitions, article excerpt, and posting provided above were previously submitted in 
the Interview Summary, with which the Examiner has not disagreed. As noted there, although 
they are not comprehensive the undersigned believes that they are representative of how one of 
skill would understand the relationship between LANs, WANs, and frame relay before reading 
the application. This includes the understandings that (a) LANs and WANs are not readily 
interchangeable, and (b) frame relay is associated with WANs as opposed to WANs. 

One of skill would not expect to find frame relay in a LAN, and would instead associate 
frame relay with WANs. Since the application does not suggest otherwise, one of skill would 
therefore understand private networks to be WANs rather than LANs. 

Moreover, the text and figures of the application treat a private network as something that 
connects local and remote sites; page 1 3 refers to "remote sites" and "distant networks". LANs 
are local area networks, whereas WANs are wide area networks spanning large regions. One of 
skill would therefore understand that the private network connecting one site with another distant 
or remote site is a WAN, not a LAN. It follows that the private network interfaces 706 are 
interfaces to WANs, not to LANs. 

Likewise, the application treats LANs - when they are present - as something located 
within a site. See, e.g., page 3 line 20 ("LANs at each site 102"). Accordingly, a "site interface 
702 connects the controller 502 to the LAN at the site 102." Page 13 lines 21-22. When a LAN 
is present, the LAN interface in the claimed controller 502 (Figure 7) is thus the site interface 
702, not a private network interface 706. 

The discussion of Figure 6 on page 12 also refers to "WAN ports of the routers 104 on 
each frame cloud 106". This reinforces the understanding of one of skill that private networks 
106 (page 4 line 5), such as frame relay networks 106 (page 5 line 5), are WANs rather than 
LANs. 

One of skill would also understand that LANs are optional. See page 17 lines 16-17, and 
note also that the term "site interface" was used for part 702 rather than "LAN interface" to allow 
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the possibility that no LAN is present at a particular site. By contrast, private networks are not 
optional - they are always present in the context of the claimed invention because a purpose of 
the invention is to access them. It follows that LANs are not private networks, because if they 
were they would be simultaneously optional and mandatory, which does not make sense. 

In short, "private networks" as claim limitations are frame relay networks and/or point-to- 
point networks. The application's "private networks" would be understood as WANs, not as 
LANs. Kitai' s LANs do not serve as "private networks" and the rejections that rely on Kitai to 
supply the teaching of a private network (Groups I-IV, VI) should be withdrawn or reversed for 
at least that reason. 

Claims L 3, and 8-9 (Group D were not properly rejected under Section 102 in view of Kitai 

It is well-established law that a rejection under Section 102 is not proper when the cited 
reference fails to teach one or more of die claimed limitations - all claimed limitations must be 
taught by the reference, or else the rejection will be overturned. See, e.g., MP.E.P. § 2131 and 
cases cited therein. As explained below, the rejections of claims 1,3, and 8-9 are not proper 
because Kitai fails to teach the "private networks" limitations of those claims. 

Claim 1 is limited to "private networks" in a parallel network configuration. Claim 1 is 
expressly limited to a "controller which controls access to multiple independent private 
networks. . . ." Claim one expressly recites "at least two private network interfaces" to access the 
parallel networks. A "private network interface" is an interface to a "private network"; see, e.g., 
the application at page 16 lines 1-3, which states: "The controller 502 also includes two or more 
private network interfaces 706, namely, so there is at least one interface 706 per private network 
106 to which the controller 502 controls access." (emphasis added). Thus, parallel "private 
networks" are clearly limitations of claim 1, and hence parallel "private networks" are also 
limitations of dependent claims 3 and 8-9. 

Kitai does not teach such private networks. As explained above, the LANs disclosed in 
Kitai are not private networks. A keyword search of Kitai reveals no use of "frame relay", and 
no use of "point-to-point". There is likewise no discussion of "Tl" or "T3" connections in Kitai. 
The term "private network" was coined for use in the present application, so it would not 
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necessarily mean the same thing even if it were present in Kitai, but it is not present in Kitai. 
Accordingly, Kitai does not teach private networks. 

Because Kitai fails to teach the parallel "private networks" limitations of claim 1 and its 
dependent claims, it is not proper to reject those claims under Section 102 based on Kitai. The 
rejections should be withdrawn or reversed. 

Claims 2, 4, 1 1, and 13-16 (Group ID were not properly rejected under Section 103 in view of 
Kitai combined with Pearce 

These rejections are improper because the references were not properly combined, and are 

also improper because the combination fails to teach private networks. 

As a justification for combining Kitai and Pearce, the Office Action asserts at the top of 
page 5 of the First Action that the combination would have been obvious "because it would have 
an efficient communication system to control and select the reliable, qualifiable network among 
multiple networks." No supporting citation to Kitai, to Pearce, or to any other source of prior art 
was given. After the Response pointed out that the assertion was unsupported, the Final Action 
repeated the assertion with a citation to "col. 2 lines 61 -col. 3 lines 5". The Final Action failed to 
state whether this was a citation to Kitai or a citation to Pearce, but it is apparently a citation to 
Pearce, since it would otherwise begin in mid-sentence. 

The Office has not identified anything specific in the cited portion of Pearce that would 
have suggested or motivated one of skill to consider Kitai in the context of Pearce. Pearce 
discusses a prioritized list of qualifying networks, but Kitai does not mention "prioritized" 
networks or "qualifying" networks. Pearce also discusses more general concepts here, such as 
networks, transmission, and receiving devices, which do appear in Kitai but also appear in other 
references. The Office fails to provide specific evidence of anything in Pearce that would have 
led one of skill to Kitai, as opposed to any other reference. 

It is well-established patent law that a rejection under Section 103 requires evidence of a 
suggestion or motivation in the prior art to combine the references. See, e.g., M.P.E.P. §§ 2142, 
2143.01, and cases cited therein. A general unsupported assertion that the combination would be 
efficient and reliable is not specific evidence that one of skill would have combined these two 
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particular references. The cited portion of Pearce also fails to provide the necessary suggestion 
or motivation. Because the combination is improper, the rejections under Section 103 based on 
Kitai with Pearce should be withdrawn or reversed. 

Furthermore, the combination does not teach private networks. Independent claim 13, 
like independent claim 1 , expressly requires "private networks" and "private network interfaces" 
(namely, interfaces to private networks). But a keyword search of Pearce reveals no use of 
"frame relay", and no use of "point-to-point". There is likewise no discussion of "Tl" or "T3" 
connections in Pearce. There is no use of "private network" in Pearce. The Final Action asserts 
that packet-switched Ethernet networks, mentioned in Pearce at column 2 line 22, are private 
networks, but Ethernet is treated in the application (page 14 line 2) as a LAN technology. As 
discussed above, LANs are not private networks. 

Accordingly, even if Pearce and Kitai are combined they fail to teach the "private 
network" limitations of these claims. This is another reason to withdraw or reverse the rejections 
under Section 103 based on Kitai with Pearce. 

Claims 5 and 17 (Group IIP were not properly rejected under Section 103 in view of Kitai 
combined with Dutta 

These rejections are improper because the references were not properly combined, and are 
also improper because the combination fails to teach private networks. 

As a justification for combining Kitai and Dutta, the First Office Action asserts on page 9 

that the combination would have been obvious "because it would improve the data transferring 

more secure and efficient." No supporting citation to Kitai, to Dutta, or to any other source of 

prior art was given. After the Response pointed out that the assertion was unsupported, the Final 

Action repeated the assertion with a citation to "col. 1 lines 29-63". The Final Action failed to 

state whether this was a citation to Kitai or a citation to Dutta, but it is apparently a citation to 

Dutta, since it would otherwise begin in mid-sentence. The Final Action also asserts, on page 3 : 

Dutta teaches a firewall regulates the flow of packetized information and prevent 
unauthorized access to or from a private network. All messages entering or leaving the 
intranet pass through the firewall, which examines each message and blocks those that do 
not meet the specified security criteria. 
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The Office has not identified anything specific in the cited portion of Dutta that would 
have suggested or motivated one of skill consider Kitai in the context of Dutta. Dutta does 
discuss a firewall and security, but Kitai does not mention "firewall" or "security". Dutta also 
discusses more general concepts here, such as packets and flags, which do appear in Kitai but 
also appear in other references. The Office fails to provide specific evidence of anything in Dutta 
that would have led one of skill to Kitai, as opposed to any other reference. 

Furthermore, the combination does not teach private networks. As pointed out in the 
Response, and not rebutted in the Final Action, a keyword search of Dutta reveals no use of 
"frame relay", and no use of "point-to-point". There is likewise no discussion of "Tl" or "T3" 
connections in Dutta. Accordingly, even if Kitai and Dutta are combined, they fail to teach the 
"private network" limitations of the claims. This is another reason to withdraw or reverse the 
rejections under Section 103 based on Kitai with Dutta. 



Claims 6 and 7 (Group IV) were not properly rejected under Section 103 in view of Kitai 
combined with Goldszmidt 

As a justification for combining Kitai and Goldszmidt, the Office Action asserts on page 

10 of the First Action that the combination would have been obvious because it "would have an 

efficient communication system to process control and monitor the delivery of packet to control 

the traffic load." After the Response pointed out that the assertion was unsupported, the Final 

Action repeated the assertion with a citation, apparently to Goldszmidt: 

In this case, the reason to combine the teachings of Kitai and Gldszmidt to have the 
controller sends packets out of sequence order because would have an efficient 
communication system to process, control and monitor the delivery of packet to control 
the traffic load (col. 2 lines 65-col. 3 lines 11). 

But Goldszmidt is about receiving packets out of sequence, not sending them out of 
sequence. As noted at column 1 1 lines 7-9: "Each packet may travel along a different route and 
arrive at their destination at different times or out of sequence and the receiving computer 
reassembles the original information." Goldszmidt views out-of-sequence packets as a problem 
to be addressed, not as an advantage. Goldszmidt does not teach intentionally sending packets 
out of sequence, as required by claims 6 and 7. Kitai does not even discuss packet "sequence". 
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Accordingly, the combination of Kitai with Goldszmidt is not motivated by Goldszmidt, and 
even if it were it fails to teach the claimed limitation of sending packets out of sequence. The 
rejections should be withdrawn or reversed. 

Further, with respect to the encrypted sequence number limitation of claim 7, neither 
Kitai nor Goldszmidt even mentions encryption, much less teaches the claimed limitation. This 
is yet another reason to withdraw the rejection of claim 7. 

Claims 10, 12, and 18 (Group V) were not properly rejected under Section 103 in view of Kitai 
combined with Albright 

As a justification for combining Kitai and Albright, the Office Action asserts on page 1 1 

of the First Action and page 14 of the Final Action that the combination would have been 
obvious "because it would have an efficient communications system that provides a number of 
point-to-point channels with different carriers and clocks through multiplexing network to 
improve network traffic and failure." But no supporting citation to Kitai, to Albright, or to any 
other source of prior art was given to support this asserted motivation. A general unsupported 
assertion that the combination would be efficient is not specific evidence that one of skill would 
have combined these two particular references. The portion of Albright cited by the Office does 
not point the reader toward Kitai any more than it points to some other network reference. Kitai 
does not mention "frame relay" or "clock", the features highlighted in the office actions next to 
the citation. 

The Final Action also asserts Albright's passing mention of Ethernet as a reason one of 
skill would have combined Albright with Kitai. But Kitai does not mention "Ethernet". 

Likewise, although the Final Action asserts Albright's network interface teachings as a 
ground for combining Albright and Kitai, those network interfaces in Albright are interfaces to a 
frame relay network; Kitai does not mention "frame relay". 

Moreover, the alleged justification for combining the references, and the reliance on 
Albright, each apparently confuse serial networks with parallel networks. Serial networks are in 
series, with a packet traveling first through one network and then through the other; if one of the 
networks in a serial configuration fails, then a packet cannot complete its trip. Parallel networks 
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are side-by-side, so a packet travels through one network or the other network but not both; if one 

of the networks fails then the packet can complete its trip without using the foiled network by 

using the other network instead. Albright teaches use of serial network configurations, as shown 

for instance in Albright Figures 1, 2, and 3. Figure 2 of Albright shows parallel links between 

two serial networks but the networks themselves are in series, not parallel. By contrast, the 

present invention is directed to parallel networks, as stated expressly in the claims and illustrated 

for example in application Figures 5 and 6. 

Albright's reliance on series networks is further evident in Albright's focus on NNIs - 

network-to-network interfaces used to connect two networks in series. NNI's are discussed in 

the present application's discussion of prior art at page 5: 

Figure 4 illustrates a prior art response to the incompatibility of frame relay networks of 
different carriers. A special "network-to-network interface" (NNI) 402 is used to reliably 
transmit data between the two frame relay networks A and B. NNIs are generally 
implemented in software at carrier offices. Note that the configuration in Figure 4 does 
not provide additional reliability by using two frame relay networks 106, because those 
networks are in series rather than in parallel. If either of the frame relay networks A, B in 
the Figure 4 configuration fails, there is no path between site 1 and site 2; adding the 
second frame relay network has not increased reliability. By contrast, Figure 1 increases 
reliability by placing the frame relay networks in parallel, so that an alternate path is 
available if either (but not both) of the frame relay networks fails. Someone of skill in the 
art who was looking for ways to improve reliability by putting networks in parallel would 
probably not consider NNIs pertinent, because they are used for serial configurations 
rather than parallel ones, and^ding networks in a serial manner does not improve 
reliability. 

Accordingly, the rejections based on Albright and Kitai should be withdrawn or reversed, 
because the combination is improper and because the combination fails to teach the claimed 
parallel private network innovations. 

Claims 19-21 (Group VP were not properly rejected under Section 103 in view of Kitai 
combined with Pearce and with Goldszmidt 

Claim 19 provides a new method for combining connections for access to multiple 

independent parallel frame relay networks. As elsewhere in the office actions, however, the only 

asserted ground for combining the references to reject this invention is a broad one ("reliability 
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and security" and efficiency) that could be asserted for almost any combination of references - 
these reasons are not specific to these particular references. Nor is any evidence given of a 
suggestion or motivation in the art that would have led one of skill to focus on and combine these 
three references rather than focusing on other references. For at least this reason, the rejections 
of claims 19-21 should be withdrawn. 

Conclusion 

For at least the reasons explained above, all rejections should be withdrawn or reversed. 
If any questions might be answered by telephone, the undersigned invites a call at the Office's 
convenience. 

The Commissioner is hereby authorized to charge any additional fee or to credit any 
overpayment in connection with this Appeal Brief to Deposit Account No. 20-0100. 
Dated this August 1 7, 2004. 




THORPE NORTH & WESTERN, LLP 

Customer No. 20,55 1 

P.O. Box 1219 

Sandy, Utah 84091-1219 

801-566-6633 (voice) 

801-566-0750 (fax) 
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CLAIMS ON APPEAL 



1 . A controller which controls access to multiple independent private networks in a 
parallel network configuration, the controller comprising: 

a site interface connecting the controller to a site; 
at least two private network interfaces; and 

a packet path selector which selects between private network interfaces according to a 
specified criterion; 

wherein the controller receives a packet through the site interface and sends the packet 

through the private network interface that was selected by the packet path selector. 

2. The controller of claim 1 , wherein the controller control access to multiple 
independent frame relay networks, and each of the at least two private network interfaces 
comprises a frame relay network interface. 

3. The controller of claim 1 , wherein the packet path selector selects between private 
network interfaces according to a load-balancing criterion, thereby promoting balanced loads on 
devices that cany packets after the packets leave the selected private network interfaces. 

4. The controller of claim 1 , wherein the packet path selector selects between private 
network interfaces according to a reliability criterion, thereby promoting use of devices that will 
still carry packets after the packets leave the selected private network interfaces, when other 
devices that could have been selected are not functioning. 

5. The controller of claim 1 , wherein the packet path selector selects between private 
network interfaces according to a security criterion, thereby promoting use of multiple private 
networks to cany different pieces of a given message so that unauthorized interception of packets 
on fewer than all of the private networks used to carry the message will not provide the total 
content of the message. 
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6. The controller of claim 1 , wherein the controller sends packets out of sequence 
over the parallel private networks. 

7. The controller of claim 6, wherein the controller places an encrypted sequence 
number in at least some of the packets which are sent out of sequence. 

8. The controller of claim 1 , wherein the controller comprises at least three frame 
relay network interfaces, each of which is selectable by the packet path selector. 

9. The controller of claim 1 , wherein the controller operates in a system providing at 
least one point-to-point connection. 

10. The controller of claim 1, wherein the controller operates in a system providing 
connectivity over at least two frame relay networks from at least two carriers, each frame relay 
network operating on its own clock which is different from the clock of the other frame relay 
network. 

1 1 . The controller of claim 1 , wherein each private network interface is an indirect 
interface tailored to a particular type of frame relay network. 

12. The controller of claim 1 , wherein each private network interface is a direct 
interface comprising an Ethernet card. 

13. A method for combining connections for access to multiple parallel private 
networks, the method comprising the steps of: 

obtaining a controller, the controller comprising a site interface, at least two private 
network interfaces, and a packet path selector which selects between private 
network interfaces according to a specified criterion; 
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connecting the controller site interface to a site to receive packets from a computer at the 
site; 

connecting a first private network interface of the controller to a first private network; 
connecting a second private network interface of the controller to a second private 

network which is parallel to and independent of the first private network; and 
sending a packet to the site interface which then sends the packet through a private 

network interface selected by the packet path selector. 

14. The method of claim 1 3, wherein the private networks are frame relay networks. 

15. The method of claim 13, further comprising the step of specifying the criterion for 
use by the packet path selector, wherein the specified criterion is a load-balancing criterion. 

1 6. The method of claim 13, further comprising the step of specifying the criterion for 
use by the packet path selector, wherein the specified criterion is a reliability criterion. 

17. The method of claim 13, further comprising the step of specifying the criterion for 
use by the packet path selector, wherein the specified criterion is a security criterion. 

1 8. The method of claim 13, wherein at least one of the steps connecting a private 
network interface of the controller connects the controller to a User-to-Network Interface in a 
router of a frame relay network. 

19. A method for combining connections for access to multiple independent parallel 
frame relay networks, the method comprising the steps of: 

sending a packet to a site interface of a controller, the controller comprising the site 
interface which receives packets, at least two network interfaces, and a packet 
path selector which selects between network interfaces according to a specified 
criterion; and 
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specifying the criterion for use by the packet path selector, wherein the specified criterion 
is one of: a security criterion, a reliability criterion, a load-balancing criterion. 

20. The method of claim 1 9, wherein the step of sending a packet to the controller site 
interface is repeated as multiple packets are sent, the step of specifying a criterion specifies a 
security criterion, and the controller sends different packets of a given message to different frame 
relay networks. 

21 . The method of claim 19, further comprising the step of sensing failure of one of 
the parallel frame relay networks and automatically sending traffic through at least one other 
parallel frame relay network. 
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